Communication between multiple partitions employing host-network interface

ABSTRACT

In a mainframe class data processing system having multiple logical partitions and a port to a network, a host-network interface is established for reducing network overhead at the multiple partitions. The host-network interface includes, for example, a host channel connection coupling the multiple partitions of the host system to a communications adapter having a network device driver for each network coupled to the adapter. The adapter also includes an address resolution protocol (ARP) cache designed to hold predetermined media headers for the clients coupled to the network(s) for use in forwarding an internet protocol (IP) datagram across the network to one of the clients from a partition of the host system. Provision is also made for partition-to-partition communication of IP datagrams by storing IP addresses of the logical partitions as HOME addresses in the ARP cache of the adapter.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation application of and contains subjectmatter which is related to the subject matter of the followingapplications, each of which is assigned to the same assignee as thisapplication. Each of the below-listed applications is herebyincorporated herein by reference in its entirety:

“METHOD FOR NETWORK COMMUNICATIONS OF MULTIPLE PARTITIONS EMPLOYINGHOST-NETWORK INTERFACE”, by Gioquindo et al., filed Sep. 14, 1998 nowU.S. Pat. No. 6,330,615, Ser. No. 09/152,369;

“SYSTEM FOR NETWORK COMMUNICATIONS OF MULTIPLE PARTITIONS EMPLOYINGHOST-NETWORK INTERFACE,” by Gioquindo et al., filed Sep. 14, 1998 U.S.Pat. No. 6,330,616, Ser. No. 09/152,370; and

“NETWORK COMMUNICATIONS OF MULTIPLE PARTITIONS EMPLOYING HOST-NETWORKINTERFACE,” by Gioquindo et al., filed Sep. 14, 1998, Ser. No.09/152,771.

TECHNICAL FIELD

The present invention relates in general to network communications ofprocessing systems. More particularly, the invention relates totechniques for effecting communications between a network and multiplepartitions of a data processing system employing a host-networkinterface.

BACKGROUND OF THE INVENTION

Mainframe class data processing systems have hardware and softwarefacilities that enable partitioning thereof. Such processing systems maybe subdivided into multiple partitions whereby a user of a partition, orsoftware executing in a partition, has the impression that theprocessing system is exclusively used by that application. Eachpartition has the appearance of being a separate and distinct processingsystem and may even run its own multi-tasking and multi-user operatingsystems independent from each other partition. An IBM Enterprise SystemsArchitecture (“ESA”)/390 Mainframe Computer is an example of one suchpartitionable mainframe class data processing system. Partitioningthereof is described in, for example, various publications byInternational Business Machines Corporation, including “IBM ESA/390Principles of Operation”, IBM Publication No. SA22-7201-02, December1994, and in the “IBM Enterprise System/9000 Processor Resource/SystemsManager Planning Guide”, IBM Publication No. GA22-7123-11 (April 1994),which are both hereby incorporated herein by reference in theirentirety.

Software executing in individual partitions within the mainframe classdata processing system may require a network connection such as a localarea network (“LAN”) connection or a wide area network (“WAN”)connection. This may be used to facilitate connectivity to users, or toapplication programs used in, for example, a client-server processingenvironment. Shown in FIG. 1 is a conventional configuration used toconnect individual partitions, including the software running therein,to a LAN. The configuration includes a processing system 11 that haspartitions 13, 15, 17, 19, 20 and 21.

Network connectivity for each partition of system 11 of FIG. 1 isachieved using separate network interfaces for each partition. Forexample, partition 13 is conventionally connected through channelconnection 29 to an IBM 3172 Interconnect Controller 23 (with 8232Channel Interface Attachment) that has, for example, a token ring orEthernet LAN port 32 attached to LAN 37 thereby providing LAN connection31. Network connectivity is accordingly directly provided betweenpartition 13 and computers 43 and 45 on LAN 37 through the IBM 3172 23.However, according to conventional techniques, this configuration has noother direct logical or physical connections from any of the otherpartitions to LAN 37. To further note, each application within partition23 must communicate with a different network port on IBM 3172 23. TheIBM 3172 (having internal 8232 Channel Interface Attachment), isdescribed in a publication entitled “8232 LAN Channel Station”, Apr. 15,1998, IBM Publication No. ZZ25-8577-0, that is incorporated herein byreference in its entirety.

The conventional software executing on IBM 3172s restricts directlogical connectivity to being between a single partition and itscorresponding LAN. Thus, to facilitate direct connectivity from acomputer 47 on a LAN 39 to both partition 17 and 21, multiple IBM 3172swould traditionally be used. Partition 17 is coupled to LAN 35 viachannel connection 29′, IBM 3172 25 and LAN port 34 thereby establishingLAN connection 33. Similarly, partition 21 is coupled to LAN 39 viachannel connection 29″, IBM 3172 27, and LAN port 35 therebyestablishing LAN connection 36.

The conventional host-to-network connectivity techniques discussed abovehave several limitations. Connectivity between a single network (i.e.,LAN or WAN) and multiple partitions require the use of multipleinterfaces therebetween such as, for example, multiple IBM 3172s.Further, each application executing in a single partition must use adifferent port on the IBM 3172 corresponding to the single partition.

An enhanced network interface for a mainframe class data processingsystem having multiple partitions and a port to a network is describedin commonly assigned U.S. Pat. No. 5,740,438, which is herebyincorporated herein by reference in its entirety. Briefly summarized,this patent describes establishing a table which defines communicationspaths between the port to the network and at least two partitions of themultiple partitions. More specifically, each partition has at least oneapplication executing therewithin and the communications paths aredefined thereto. Data frames are passed between the network and theapplications within the partitions through the port to the network andalong the communications paths defined in the table such that thenetwork communications is effected.

One embodiment of the network interface approach of U.S. Pat. No.5,740,438 is depicted in FIG. 2. Shown is a partitionable mainframeclass data processing system 11 (e.g., an IBM Enterprise System/9000)having an integral host-to-network interface (“HNI”) 51 that facilitatesa LAN connection 55 from multiple partitions 13, 15, 17, 19, 20 and 21to LAN 53 through LAN port 54. Each application in each partition maydirectly communicate with computers 61, 63 and 65 on LAN 53 through thesingle host-to-network interface 51 and single LAN port 54. The LANshown is a token ring LAN; however, the system is equally applicable toother types of LANs such as, for example, Ethernet and Fiber DistributedData Interface (“FDDI”). Further, the host-to-network interface maysupport multiple network connections by way of multiple network ports.For example, a WAN connection 57 comprising, for example, a Peer-to-PeerProtocol (“PPP”) connection may be established to a computer 59 throughWAN port 56. Any mix of LAN and WAN connections among multiple ports ofhost-to-network interface 51 is possible.

The host-to-network connectivity techniques described above have certainlimitations, particularly in an Ethernet environment where two differentframe types are possible, i.e., Ethernet DIX and Ethernet 802.3. Forclient/server systems, Transmission Control Protocol (TCP)/InternetProtocol (IP) has become the leading protocol for networkcommunications. Using Ethernet, when a client application running overTCP/IP wants to communicate with a server application, the applicationmust specify one of the two existing Ethernet frame formats. The frameformat must also be known by the server machine in order for the TCP/IPconnection to be established and any data transfer to occur.Conventionally, in order to make sure that the client and servercommunicate using the same Ethernet frame formats, both the client andserver must specify the specific frame format to be used in theirappropriate configuration files. If the configuration files do notmatch, then the client/server application will not work properly.

The most common server TCP/IP environment today has the complete TCP/IPfunctionality on one platform. For example, reference “TCP/IP Tutorialand Technical Overview,” IBM Document No. GG24-3376-03 (December 1992).In this environment, one device driver exists in each partition for eachLAN connection. Each device driver can specify a different Ethernetframe format, but will not support both frame formats. Thus, a differentdevice driver is used for each of the two frame formats. In operation, adedicated device driver of a partition of the host system takes care ofproviding both channel headers and media or LAN headers necessary fortransmission of an IP packet across the LAN to a client coupled thereto.Again, however, this dedicated device driver is configured to functionwith one particular type of LAN, and with respect to Ethernet, oneparticular frame format.

With the above as background, the present invention is directed toenhancements to the state-of-the-art of network communications ofmultiple partitions employing a host-network interface.

DISCLOSURE OF THE INVENTION

Briefly summarized, the present invention comprises in one aspect amethod of network communications implemented within a host-networkinterface for use in a mainframe class data processing system havingmultiple partitions, and a port to a network. This method includes:saving at the host-network interface an internet protocol (IP) addressfor at least one of the multiple partitions of the mainframe class dataprocessing system; generating an IP datagram at a first partition of themultiple partitions to be forwarded to a second partition of themultiple partitions using a destination IP address; and determiningwhether the destination IP address for the IP datagram comprises a savedIP address at the host-network interface of the at least one partitionof the mainframe class data processing system, and if so, forwarding theIP datagram directly from the first partition to the second partitionwithout employing the network.

Systems and computer program products corresponding to theabove-summarized method are also described and claimed herein.

Network communications in accordance with the principles of the presentinvention provides numerous advantages over the existing art for amainframe class data processing system having a port coupled to anetwork. For example, reduced configuration information is required atthe host system since the user application does not have to specify thenetwork type in the host configuration. In one aspect, this isaccomplished by providing a technique for dynamically determining anEthernet frame format at the communications adapter of the host-networkinterface coupling the host system to the network. Further, inaccordance with this invention, only one common non-network specificchannel device driver is needed at each logical partition of the hostsystem, and one network, e.g., LAN, device driver at each port of thenetwork adapter. Less internet protocol addresses are therefore neededfor host connections to the network. Advantageously, one single IPaddress within a partition can be used to communicate with any number ofdifferent networks, e.g., token ring, Ethernet DIX or Ethernet 802.3.This contrasts with existing configurations, wherein for each uniquenetwork type, and for each Ethernet frame type, a different IP addressmust be specified within the partition. Further, partition-to-partitiontraffic is facilitated herein without requiring a network connection toroute an internet protocol (IP) datagram from a first logical partitionto a second logical partition of the host data processing system.

BRIEF DESCRIPTION OF THE DRAWINGS

The above-described objects, advantages and features of the presentinvention, as well as others, will be more readily understood from thefollowing detailed description of certain preferred embodiments of theinvention, when considered in conjunction with the accompanying drawingsin which:

FIG. 1 is a system diagram of a conventional network connectedpartitionable mainframe class data processing system;

FIG. 2 is a system diagram of an alternate embodiment of a networkconnected partitionable mainframe class data processing system;

FIG. 3 is a system diagram of one embodiment of a network connectedpartitionable mainframe class data processing system pursuant to thepresent invention;

FIGS. 4a & 4 b are simplified block diagrams of the two Ethernet frameformats in common use;

FIG. 5 depicts one embodiment of an Address Resolution Protocol (ARP)cache implemented within a host-network interface in accordance with thepresent invention;

FIG. 6 is a flow diagram of communications in accordance with thepresent invention between a first partition and a second partition in acommon mainframe class data processing system;

FIG. 7 is a flow diagram of communications in accordance with thepresent invention between a partition of the system and a client on anetwork coupled to the mainframe class data processing system;

FIG. 8a is a block diagram of a conventional embodiment of the layers tobe constructed for an internet protocol (IP) packet to be transmittedfrom a partition at the host system onto a local area network (LAN) viaan adapter coupled between the host system and the network; and

FIG. 8b is a block diagram of one embodiment of the layers to beconstructed for an IP packet to be transmitted from the host system,across the adapter and onto a LAN in accordance with the presentinvention.

BEST MODE FOR CARRYING OUT THE INVENTION

As noted, a common communications protocol for the mainframe environmenttoday is the Transmission Control Protocol/Internet Protocol (TCP/IP).TCP/IP communications is described in, for example, the above-noteddocument entitled “TCP/IP Tutorial and Technical Overview,” IBM DocumentNo. GG24-3376-03, published December, 1992, which is hereby incorporatedherein by reference in its entirety. The present invention employs,e.g., TCP/IP communications with certain TCP/IP functionality beingmigrated from the host system to a second platform, herein referred toas the host-network interface. FIG. 3 depicts one embodiment of acommunications network 100 in accordance with the present inventionwherein an IBM S/390 host system 111 is coupled to multiple local areanetworks across a host-network interface which comprises a host channelconnection 118 and a communications adapter, such as an IBM Open SystemsAdapter (OSA) 120. The OSA 120 may be platform channel attached to orintegrated with the mainframe environment. In the OSA environment, theTCP/IP address resolution protocol (ARP) function has been migrated tothe OSA platform 120.

In accordance with the present invention, the OSA adapter has thecapability of supporting any number of different TCP/IP connectionsthrough a common network device driver, such as LAN 1 device driver 122and LAN 2 device driver 124. Further, pursuant to this invention, theHOST applications are no longer required to know anything about the LANor wide area network (WAN) media over which they are communicating.Since only one channel device driver per network is to be employed,provision is made herein for the network device driver to support bothEthernet DIX and Ethernet 802.3 formats. In addition, the OSA has thecapability to dynamically determine which Ethernet frame type aparticular client platform supports for a current connection. Each ofthese aspects of the invention, as well as others, is described indetail hereinbelow.

FIG. 3 shows three separate HOST logical partitions (LPARs) orpartitions. As is well known, each LPAR functions as its own separateentity, with each logical partition (LPAR) of the host system 111 beingviewed as a completely separate entity. The TCP/IP box within each LPARdefines a unique TCP/IP stack 112, 114, 116, which can functionindependently of the others. The IP fields are the unique IP addressesdefined for each TCP/IP stack. A TCP/IP stack can have one or more IPaddresses defined.

Each logical partition LPAR 1 113, LPAR 2 115, LPAR 3 117, couplesthrough a Host Channel Connection 118 to a communications adapter 120,such as IBM's Open Systems Adapter (OSA). The OSA adapter, which has aconnection to each of the TCP/IP stacks, is an integrated channelattached LAN adapter which does not contain its own TCP/IP stack. TheHost Channel Connection 118 comprises as one example an IBM EnterpriseSystem Connection (“ESCON”) channel connector. The LAN device drivers122, 124 and the Address Resolution Protocol cache 123 are contained inthe OSA adapter 120. This is different from other channel attachedadapters which do not contain the IP functionality. For background on anAddress Resolution Protocol (ARP) cache or table, reference a textbookby W. Richard Stevens entitled TCP/IP Illustrated, published byAddison-Wesley, Volume 1 (1994), the entirety of which is herebyincorporated herein by reference.

Previously, each logical partition was required to contain its own LANdevice driver. Pursuant to the present invention, however, multiplelogical partitions are shown in FIG. 3 as sharing a common networkdevice driver 122 or 124 for accessing network 130, 140, respectively,coupled to the host system 111. By way of example, OSA adapter 120 isshown connected to two different LANs, i.e., LAN 1 130 and LAN 2 140.These LANs can be different media types, e.g., Fiber Distributed DataInterface (“FDDI”), token ring, or Ethernet. Further, each LAN 130, 140includes a representative client platform 135 & 145. The numbersdepicted in the client platforms are representative of IP addresses usedin accessing the particular platforms.

As briefly noted above, one aspect of this invention comprises providingthe host-network interface with the capability to dynamically determineor predetermine the particular Ethernet frame format needed for a LANdevice driver, for example, LAN 1 device driver 122, to communicateacross the network with a client 135 coupled to the network. In anEthernet environment, there are two different frame formats in commonuse, i.e., Ethernet 802.3 and Ethernet DIX, for client platforms whichcan co-exist on the Ethernet network. FIGS. 4a & 4 b depict the fieldsof the Ethernet 802.3 and Ethernet DIX formats, respectively. Adescription of these fields is set forth below:

DA1-DA6—this field is the destination MAC address which comprises theMedia Access Control address of a port on the destination LAN adapter.By way of example, the destination address is six bytes in length.

SA1-SA6—this is the source MAC address which comprises the media accesscontrol address of a port on the sending LAN adapter. In this example,the source address is six bytes.

Frame length—this is the length of an Ethernet frame, including lengthof LLC, SNAP and IP datagram. In one example, the frame length is twobytes.

LLC—this field comprises the Logical Link Control field and contains,for example, protocol information. Protocol is the networking protocolthat the application is using. Examples of networking protocols includeTCP/IP, “NETBIOS,” “IPX” (used in “Novell” networks) and Systems NetworkArchitecture (“SNA”). The LLC field in Ethernet 802.3 format maycomprise three bytes.

SNAP—identifies the Sub-Network Access Protocol within the LAN packet.In one example, the SNAP header may be five bytes.

Ethernet Type—identifies the protocol of the data that follows theEthernet type in the frame. The Ethernet type of Ethernet DIX format istwo bytes in length.

MAC—this is the Media Access Control field which contains, for example,broadcast indications and other LAN specific information.

To eliminate from the host the conventional configuration informationotherwise needed for each IP session to identify the Ethernet frame typeused between a client/server application, the present inventionimplements a technique which dynamically solicits the client platform todetermine which Ethernet frame type is being used. To accomplish this,the OSA adapter implements the following:

When an IP datagram is received from a host partition which is to berouted to a new Ethernet client platform, two separate ARP packets areconstructed. A first ARP packet is constructed using the Ethernet DIXframe format and a second ARP packet is constructed using the Ethernet802.3 format. Both frame formats are then broadcast across the network.

The client platform only responds to the ARP request which has theproper frame format. The other ARP will be dropped by the destinationclient platform upon its receipt.

When the client's ARP response is received back at the source system,its OSA adapter will know which frame format to use for the pending orfuture IP session(s) with that client.

Advantageously, employing the above concept results in lessconfiguration information being needed at the host system. That is, theuser application does not have to specify the LAN type in its hostconfiguration.

Along with dynamically identifying the Ethernet frame format being usedby a client machine, the present invention also includes storing mediaheaders in the ARP table (or ARP cache) employed by the communicationsadapter. (As used herein, a “media header” refers to the MAC header, andis also referred to as a LAN header or WAN header.) For example, uponreceipt of an ARP response from a client to a broadcast ARP request, theLAN header which defines the Ethernet frame format of the client machineis obtained from the response and stored into the ARP table in a mannerwhich will be straightforward to one of ordinary skill in the art. TheARP table will thus contain two headers, one for ARP packets and one forIP packets. For Ethernet 802.3 headers, the entire MAC/LLC/SNAP headeris stored in the ARP table. For Ethernet DIX, only the MAC header isneeded. For a client which supports both Ethernet frame formats, theframe format in the first response from the client received at the OSAadapter may be used.

By storing the media header in the ARP table, the OSA adapter can thensubsequently append this header to every IP datagram being sent to thatparticular client platform without having to construct a new mediaheader each time. For Ethernet DIX packets, all the fields in the LANheader are constant, while for Ethernet 802.3, all the fields areconstant except for the Frame Length field. This field must be changedto the packet length for each packet transmitted.

Further, media headers can be predetermined by configuring thecommunications adapter to monitor ARP requests received from thenetwork. Each incoming request will also identify the Ethernet frametype being used by the source client. From such a request, the LANheaders can be obtained and pre-stored in the ARP cache for future usewith an IP request destined for that client platform as described above.Advantageously, by so pre-storing the LAN headers, the header does nothave to be constructed for each IP datagram being transmitted from theadapter and the host system is freed of any responsibility fordesignating a client's Ethernet frame format.

Another aspect of the present invention comprises designating and saving“HOME” IP addresses within the communications adapter, e.g., within theARP cache. FIG. 5 presents an example of the possible formats of the ARPentries on an OSA adapter in accordance with one embodiment of theinvention. The figure depicts two tables, namely, an ARP Base Table andan ARP Collision Chain. To find a proper entry in the OSA ARP table, anIP address is traditionally first hashed to compute a one byte indexinto the ARP Base Table, which may by way of example comprise 256 bytes.Since it is possible for two IP addresses to “hash” to the same index,the ARP Collision Table is needed to chain these additional entries tothe ARP Base Table. The IP numbers in the two tables comprise examplesof IP addresses for the application used by the particular networkingprotocol as will be apparent to one of ordinary skill in the art. Theexamples agree in part with the IP addresses provided in FIG. 3.

The information in the ARP tables is preferably obtained from the TCP/IPstacks at initialization time and from the LAN as ARP requests/responsesreceived from the network. At initialization time, each Host TCP/IPstack is configured to register its HOME IP addresses with the OSAadapter in a manner apparent to one skilled in the art. The “HOME”addresses are those which are recognized as local IP addresses by thespecific stack. These entities are marked as HOME entries in the ARPcache. The entries are unique from the ARP entries for the LAN becausethey do not contain the specific LAN frame type which is to be used intransmitting a packet. If needed, the frame format for these entries isdynamically determined as described above by the client or server in thenetwork which sends packets to the OSA adapter.

The HOME IP addresses mark the IP addresses to which OSA will respondwhen receiving an ARP request from the LAN. The format of the ARPresponse which OSA returns is the same as the format of the ARP requestwhich OSA receives. The entire MAC header used to send back an ARPresponse is thus also saved in the ARP tables on the OSA adapter. ThisMAC header is then appended to any IP datagrams received from the Hostwhich are destined for the matching IP address.

The HOME entries serve another purpose. In accordance with a furtheraspect of the invention, these entries are preferably used to routepackets from a first logical partition (LPAR) to a second LPAR of thehost system without going onto a network. When a packet is received fromthe Host, the destination IP address is “looked up” in the ARP tables ofthe host-network interface. If an entry is found and it is marked as aHOME entry, then the IP packet is routed directly to the LPAR owningthat address. Since the packet is not sent out onto a network, no mediaor network header needs to be constructed.

FIG. 6 depicts one embodiment of LPAR to LPAR communications inaccordance with this aspect of the invention. In this example, a logicalpartition, LPAR 3, is assumed to construct an IP datagram which includesan IP header, a TCP header and data, for sending to an IP address 200,which is assumed to comprise address 9.117.34.254 (see FIGS. 3 & 5). TheIP datagram is then passed to, e.g., an IBM ESCON channel driver withinhost channel connection 118 (FIG. 3) of the host-network interface, andno LAN information is provided by the LPAR in the packet 210. The packetis transmitted across the channel to, e.g., an OSA adapter 220 and theOSA adapter uses the destination IP address 9.117.34.254 to look up theentry in the ARP cache 230. As shown in FIG. 5, this particular IPaddress is designated in the collision chain as a HOME type IP address.Since a HOME IP entry is found, the IP datagram is forwarded directly toLPAR 1 from LPAR 3 without being transmitted out onto a network 240.

Packets for which a LAN entry is found are necessarily sent onto theappropriate LAN. In this example, a “LAN entry” comprises a saved IPaddress with a format type of Ethernet DIX or Ethernet 802.3 (see FIG.5). For Ethernet DIX packets, the exact media or MAC header stored inthe ARP table as described above is appended to the IP datagram. Thepacket is then forwarded to the respective LAN driver (FIG. 3) and senton to the LAN. For Ethernet 802.3 packets, the LAN header stored in theARP table is copied into a unique buffer area. The frame length field inthe LAN header is then modified to reflect the LLC/SNAP/IP datagramtotal length, and the header is appended to the IP datagram andforwarded to the LAN driver.

Packets received for which an entry cannot be found in the ARP table arepreferably queued in the ARP table. As noted above, ARP requests in bothEthernet 802.3 and Ethernet DIX formats are then transmitted onto theLAN, i.e., assuming that the LAN comprises one of the two Ethernetformats. Any subsequent IP datagrams received from the Host prior to anARP response being returned from the client across the LAN are alsopreferably queued from the ARP table entry which is “pending” the ARPresponse. Once an ARP response is received at the OSA adapter, all thequeued packets are transmitted onto the LAN.

FIG. 7 depicts one embodiment of LPAR to LAN communication in accordancewith this aspect of the invention. A logical partition, for example,LPAR 3, constructs an IP datagram which includes an IP header, TCPheader and data, for sending to an IP address, designated 10.20.20.1300. This particular address is depicted in FIG. 3 as comprising aclient coupled to LAN 1 and in FIG. 5 as being Ethernet DIX frameformat.

The IP datagram is passed to the channel driver with no LAN informationin the packet 310, for forwarding to the OSA adapter 320. The OSAadapter uses the destination IP address 10.20.20.1 to look up the entryin the ARP cache 330. Assuming that this is the first request to thatparticular address, then no entry will be found. An ARP request thus issent to IP address 10.20.20.1 using both Ethernet 802.3 and Ethernet DIXformats. IP datagrams from the Host are queued in the ARP cache entryawaiting a response from this IP address 340. An Ethernet DIX format ARPresponse is assumed received and the LAN header from the ARP response issaved in the ARP cache entry 350. For example, reference FIG. 5 where inthe example shown the IP address, and LAN or media header, is placedinto the collision chain in a manner that will be apparent to one ofordinary skill in the art. The Ethernet DIX framed IP datagram is thenforwarded to the LAN, with the LAN header from the ARP entry appended tothe IP datagram received from the logical partition 360.

To summarize, by having the ARP code and the device drivers present onthe OSA adapter, the Host's TCP/IP stacks are given the ability todefine one IP address only and have it communicate to any LAN typethrough the adapter. Prior to this invention, the host system had tohave one unique LAN device driver for each LAN type. Further, forEthernet formats, one LAN device driver was needed to be loaded forEthernet DIX connections and another for Ethernet 802.3 connections. Byplacing all the LAN specific drivers in the OSA adapter along with theARP function, one IP connection can communicate to any other IPconnection either LPAR to LPAR or LPAR to LAN using one generic channeldevice driver.

FIG. 8a shows the various layers involved in the constructing of apacket to be transmitted onto a LAN pursuant to conventional processingwherein the host system employs a unique LAN device driver for each LANtype to which the host is connected. The HOST contains the application,TCP, IP and channel/LAN device driver layers. The flow starts at theapplication layer. For example, a user issues a file transfer program(FTP) command to send a file to a client. The FTP (application) thenpasses the data to the TCP layer. The TCP encapsulates the FTP data witha TCP header. The TCP packet is then passed to the IP layer whichencapsulates the TCP packet with an IP header. The IP header/TCPheader/user data packet is known as the IP datagram. The IP datagram isthen passed to the channel/LAN device driver where the IP datagram isencapsulated with a LAN header and a channel header to send the packetacross, for example, an ESCON channel to an OSA adapter. In order forthe LAN header to be injected at the host, the host conventionallyrequires knowledge of the LAN.

Once the packet is received by OSA, the channel header is stripped andthe packet is passed to the LAN device driver which transmits the packetonto the proper LAN media.

For comparison, FIG. 8b shows the various layers involved inconstructing a packet to be transmitted on the LAN in accordance withthe present invention. The HOST contains the application, TCP, IP andchannel device driver layers. The flow starts at the application layer.For example, a user issues an FTP command to send a file to a client.The FTP (application) then passes the data to the TCP layer. TCPencapsulates the FTP data with a TCP header. The TCP packet is thenpassed to the IP layer which encapsulates the TCP packet with an IPheader. The IP header/TCP header/user data packet is known as the IPdatagram. The IP datagram is then passed to the channel device driver.The channel device driver encapsulates the IP datagram with a channelheader to send the packet across the ESCON channel to the OSA adapter.

Once the packet is received by OSA, the channel header is stripped andthe packet is passed to the OSA ARP function. The OSA ARP functionappends the LAN header from the associated ARP cache entry to the IPdatagram and passes the packet to the LAN driver. Since the ARP functionconstructed the entry's LAN header, the LAN driver does not need toconstruct a header, it just transmits the packet onto the proper LANmedia.

One skilled in the art will recognize from a comparison of FIGS. 8a & 8b that the present invention relieves the host partitions of processingoverhead associated with knowing the LAN configuration and moves theresponsibility for providing the media header to the communicationsadapter.

As one further consideration, for IP networks which run in a LANenvironment, the IP datagram which is transmitted must not exceed theMTU (Maximum Transmission Unit). The MTU is determined from the LANmedia on which the IP datagram is being transmitted. For example, forEthernet LANs, the maximum MTU is 1500 bytes for Ethernet DIX frames and1492 for Ethernet 802.3 frames. Since the MTU size determines themaximum size for an IP datagram, the smaller the MTU, the more IPdatagrams which must be constructed to transmit a block of data across anetwork. This has a direct effect on the performance of an IPconnection. For LPAR to LPAR traffic, in accordance with the presentinvention, the IP datagrams are not sent onto the LAN environment.Therefore, for LPAR to LPAR connections, the Host configuration canspecify a very large MTU (currently 64 K) which will dramaticallyincrease the performance of the IP connection.

The present invention can be included, for example, in an article ofmanufacture (e.g., one or more computer program products) having, forinstance, computer usable media. This media has embodied therein, forinstance, computer readable program code means for providing andfacilitating the capabilities of the present invention. The articles ofmanufacture can be included as part of the computer system or soldseparately. Additionally, at least one program storage device readableby machine, tangibly embodying at least one program of instructionsexecutable by the machine, to perform the capabilities of the presentinvention, can be provided.

The flow diagrams depicted herein are provided by way of example. Theremay be variations to these diagrams or the steps (or operations)described herein without departing from the spirit of the invention. Forinstance, in certain cases, the steps may be performed in differingorder, or steps may be added, deleted or modified. All of thesevariations are considered to comprise part of the present invention asrecited in the appended claims.

While the invention has been described in detail herein in accordancewith certain preferred embodiments thereof, many modifications andchanges therein may be effected by those skilled in the art.Accordingly, it is intended by the appended claims to cover all suchmodifications and changes as fall within the true spirit and scope ofthe invention.

What is claimed is:
 1. A method of network communications implementedwithin a host-network interface for use in a mainframe class dataprocessing system having multiple partitions and a port to a network,said method comprising: saving at said host-network interface aninternet protocol (IP) address of at least one of said multiplepartitions of the mainframe class data processing system; generating anIP datagram at a first partition of said multiple partitions to beforwarded to a second partition of said multiple partitions using adestination IP address; and determining whether said destination IPaddress for said IP datagram comprises an IP address saved at saidhost-network interface for said at least one partition, and if so,forwarding the IP datagram directly from said first partition to saidsecond partition of said multiple partitions without employing saidnetwork.
 2. The method of claim 1, wherein said saving comprises savingeach IP address of said at least one of said multiple partitions in anaddress resolution protocol (ARP) cache at said host-network interfaceas a HOME type IP address, and wherein said determining comprisesemploying said ARP cache to look up said destination IP address anddetermine whether said destination IP address comprises a HOME type IPaddress.
 3. The method of claim 2, wherein said saving comprises savingin said ARP cache an IP address for each partition of said multiplepartitions of the mainframe class data processing system, wherein eachIP address of said mainframe class data processing system is saved insaid ARP cache as a HOME type IP address.
 4. The method of claim 2,further comprising saving in the ARP cache an IP address for at leastone client coupled to said network, wherein said IP address of said atleast one client is saved in said ARP cache as a NETWORK type IPaddress.
 5. The method of claim 1, wherein said generating comprisesgenerating said IP datagram and forwarding said IP datagram from saidfirst partition without specifying a network environment for said IPdatagram.
 6. A system for network communications in a mainframe classdata processing system having multiple partitions and a port to anetwork, said system comprising: a host-network interface coupledbetween said multiple partitions and said network, said host-networkinterface being adapted to: save at said host-network interface aninternet protocol (IP) address of at least one of said multiplepartitions of the mainframe class data processing system; generate an IPdatagram at a first partition of the multiple partitions to be forwardedto a second partition of the multiple partitions using a destination IPaddress; and determine whether said destination IP address for said IPdatagram comprises an IP address saved at the host-network interface forsaid at least one partition, and if so, forward the IP datagram directlyfrom the first partition to the second partition of the multiplepartitions without employing the network.
 7. The system of claim 6,wherein said host-network interface being adapted to save comprisesbeing adapted to save each IP address of said at least one of saidmultiple partitions in an address resolution protocol (ARP) cache atsaid host-network interface as a HOME type IP address, and wherein saidhost-network interface being adapted to determine comprises beingadapted to employ said ARP cache to look up said destination IP addressand determine whether said destination IP address comprises a HOME typeIP address.
 8. The system of claim 7, wherein said host-networkinterface being adapted to save comprises being adapted to save in saidARP cache an IP address for each partition of said multiple partitionsof the mainframe class data processing system, wherein each IP addressof said mainframe class data processing system is saved in said ARPcache as a HOME type IP address.
 9. The system of claim 7, wherein saidhost-network interface is further adapted to save in the ARP cache an IPaddress for at least one client coupled to said network, wherein said IPaddress of said at least one client is saved in said ARP cache as aNETWORK type IP address.
 10. The system of claim 6, wherein saidhost-network interface being adapted to generate comprises being adaptedto generate said IP datagram and forward said IP datagram from saidfirst partition without specifying a network environment for said IPdatagram.
 11. An article of manufacture comprising: at least onecomputer usable medium having computer readable program code meansembodied therein for causing network communications in a mainframe classdata processing system having multiple partitions and a port to anetwork, the computer readable program code means in the article ofmanufacture comprising: (i) computer readable program code means forcausing a computer to effect saving at a host-network interface aninternet protocol (IP) address of at least one of the multiplepartitions of the mainframe class data processing system; (ii) computerreadable program code means for causing a computer to effect generatingan IP datagram at a first partition of said multiple partitions to beforwarded to a second partition of said multiple partitions using adestination IP address; and (iii) computer readable program code meansfor causing a computer to effect determining whether said destination IPaddress for said IP datagram comprises an IP address saved at saidhost-network interface for said at least one partition, and if so,forwarding the IP datagram directly from said first partition to saidsecond partition of said multiple partitions without employing saidnetwork.
 12. The article of manufacture of claim 11, wherein saidcomputer readable program code means for causing a computer to effectsaving comprises computer readable program code means for causing acomputer to effect saving each IP address of said at least one of saidmultiple partitions in an address resolution protocol (ARP) cache atsaid host-network interface as a HOME type IP address, and wherein saidcomputer readable program code means for causing a computer to effectdetermining comprises computer readable program code means for causing acomputer to effect employing said ARP cache to look up said destinationIP address and determine whether said destination IP address comprises aHOME type IP address.
 13. The article of manufacture of claim 12,wherein said computer readable program code means for causing a computerto effect saving comprises computer readable program code means forcausing a computer to effect saving in said ARP cache an IP address foreach partition of said multiple partitions of the mainframe class dataprocessing system, wherein each IP address of said mainframe class dataprocessing system is saved in said ARP cache as a HOME type IP address.14. The article of manufacture of claim 12, further comprising computerreadable program code means for causing a computer to effect saving inthe ARP cache an IP address for at least one client coupled to saidnetwork, wherein said IP address of said at least one client is saved insaid ARP cache as a NETWORK type IP address.
 15. The article ofmanufacture of claim 11, wherein said computer readable program codemeans for causing a computer to effect generating comprises computerreadable program code means for causing a computer to effect generatingsaid IP datagram and forwarding said IP datagram from said firstpartition without specifying a network environment for said IP datagram.